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We are in a time of growing perception of social and environmental difficulties, and also of 
growing social movements to engage with them. I and many others see collaboration and 
communications between these groups as a key to their success. Electronic 
communications seems to be a necessary medium for part (but not all) of this, and there is 
a growing number of projects developing such software. 

This is my contribution to that, building upon the social visions in my book, eGaia, Growing 
a peaceful, sustainable Earth through communications, and upon many years experience 
with online learning communities at the Open University. 

More specifically, this is a first draft of a specification for a software platform to support a 
network of local communities seeking sustainability and local resilience, and seeking to 
work with other similar communities across larger scales, regionally, nationally and 
globally, as for example, the Transition Network. It describes a set of linked portals: social 
networking sites enhanced for these purposes. 

The principal features are: 

1 . For individuals, a personal profile page giving basic information about themselves and 
summarising their contribution to the network, and which can be expanded to a 
personal website if desired. To enhance the sense of connection, people have 
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1 Introduction and summary of features 
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'partners' (who are people who do favours for each other) instead of 'friends' as in 
conventional social networking sites. 

2. Each group/sub-group/region/etc. has their own site that feels individual and has a 
clear (somewhat customisable) identity, with content created easily by its members 
(using simple templates), yet is clearly connected with information to and from other 
groups at the same, larger and smaller scales. 

3. Standard facilities are included such as events listings with calendars, news/blogs, 
resource centre for sharing files, pictures, and media with good indexing and search, 
map pages. All are individual to the group but with feeds and links to and from other 
groups as desired. 

4. Organisational support such as group editable pages (wiki), member lists with roles, 
agreement lists, task trackers. 

5. Enhanced communication facilities including a discussion system optimised to promote 
groups coming to agreement, with email notification and online archives, and also 
group chat, telephone conferencing and community telephone call centres. 

6. Exchange/trading system designed to promote exchange on a basis of personal 
relationship, integrity, quality, need, and environmental soundness rather than simply 
for money. (But it does include exchange for money.) It includes an innovative 
moneyless exchange based around favours. 

The sections following describe the social dimensions of the system the platform is 
intended to support, the overall architecture of the platform, its general features and with 
appendices for extended descriptions of the discussion system and exchange/trading 
system. 
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2 The social context 

This platform is intended to support the rapidly growing movement of groups, 
organisations and individuals who are working to create sustainable communities at a local 
level, linked at larger scales. The key characteristic is the desire to collaborate within and 
across groups socially and economically. 

Typically, as for example in the Transition Movement, local groups will set up an initiating 
group to engage in a series of awareness raising events for the public in their area. They 
will then form a set of theme groups to look in detail at such issues as food, transport, 
health, energy, local government, etc. They will look for help and co-operation from other 
similar groups locally and to national support organisations. The platform is intended to 
support all of these activities. 

This raises communication needs at the local, regional and national levels. 
Enhancing communications at a local level: 

• The need for initiating groups and theme groups to communicate with their members and 
each other, to maximise synergy and handle problems and conflicts. 

• The need to keep the local public informed of events, activities, initiatives and encourage 
engagement and involvement in them. 

• The need for initiating groups and theme groups to find out the best and most efficient 
ways of doing things, learning from the experiences of others, avoiding problems by and 
through accessing public resources and most importantly through contact with relevant 
people who can help and advise. 

Within regions or cities where there are several or many local initiatives: 

• The need for nearby initiatives to keep abreast of what each other is doing, to enable 
them to work together where appropriate, share ideas, share resources, run joint 
activities, support each other 

• The need for newly forming initiatives to get help in starting through the experiences of 

nearby initiatives. 

Within a national context: 

• The need to provide a public face for the network that is clear, informative and dynamic, 
presenting the changing events and activities of the movement. 

• The need to create a library of resources to help newly forming and currently active local 

initiatives. 

At all levels - exchange and trading 

• The need to develop means of trading and exchange based upon personal relationship, 

mutual support not competition and environmental soundness. 

• The need to put conventional, market-based exchange onto a more ethical basis, driven 
by well-being and community service rather than money and profit. 
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3 Overall architecture and requirements 

Centralised or distributed? 

A key issue is whether the platform should run on one centralised website or be 
decentralised at various scales. Centralisation offers simplicity in maintenance and 
upgrading. However, it also creates vulnerabilities and the possibility that the local is lost 
within it. 



A major consideration is that many of the groups for whom this platform is aimed are 
already well advanced with their own communication tools, ranging from simple html 
websites, through CMSs like Drupal, Wordpress or Plone, to commercial systems such as 
Google groups and Ning. This creates a double challenge: 

1 . To create a system that can link to those existing sites that have the ability to give and 
receive feeds. 

2. To be sufficiently attractive that at least some of the groups with existing sites will move 
over to it. 



A major problem for software systems is the need for high-quality professional 
development teams, for ongoing technical maintenance and upgrading, and then for a 
social support team that supports and encourages the grassroots members to use the 
system effectively. 

We propose a somewhat decentralised system where the existence of good technical and 
social support is the main deciding criterion for the scale of a local/regional site. 

Resilience and linking 

To promote resilience, we propose that each site should also function as a mirror for one 
or more other sites, organised so that every site has more than one mirror. This is to 
provide backup and re-building in case of difficulties. 

• Sites should mirror the other sites with whom they are most likely to exchange feeds of 
content. 

• The particular feeds selected are to be decided at the level of individual groups and sub- 
groups within a site. 

Site architecture 

Each site should be structured as a recursive set of portals, all with a similar structure and 
function, each supporting a group, sub-group, sub-subgroup, etc, with the lowest levels 
being the portals of individual users. Thus the home page would appear as a portal for the 
overall group, and it would prominently list the sub-groups, which themselves would 
appear semi-autonomous. The overall home page might belong to a national group, 
regional group, or local group (if it were sufficiently active and had sufficient support). 

To create a sense of local ownership at each level of group, 

• the home page of that portal would include summaries and links to recent content 
created by the group (ex. events, news, new pages, documents, media, discussion 
items, exchanges, etc.) 

• the portal would be somewhat customisable, perhaps through an individual logo, choice 
of colours, choice of content types and feeds to be displayed. 
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• the navigation system would display the content at that level, but with some links to 
larger-scale levels. 

• It would be desirable to create urls at the level of each group that are subdomains of the 
higher level: i.e. http://sub-group.group.overallsite.org. 

• all content in that portal would be created by members of the group or would be feeds 
from other places as determined up by the group. 

Usability 

Our intention is that larger numbers of people will use the platform, many of whom will 
have relatively little technical sophistication. Thus great attention must be paid to its 
usability both for casual browsers and people creating content. 

For ordinary users creating content there should be simple templates with only the most 
essential commands, and for ordinary users administering groups there should be simple 
administration pages to manage them (delete, assign permissions). 
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4 Overall portal specification 

Group areas 

At every level, members of a group would be able to create/add a range of standard types 
of content, such as those in many common CMSs such as Plone or Drupal: 

• event listings with an optional calendar display 

• news listings in blog format 

• images, audio, video (the latter two may possibly simply be embedded from external 
sites such as YouTube or MySpace) 

• descriptive pages that include rich text formatting, images, tables, links 

• folders to group content where desired 

• file storage for common access 

• map pages 

In addition, there are some special types of content: 

• A discussion system enhanced to encourage people to come to agreement, to promote 
collaboration. See description below. 

• Exchange/trading system designed to promote exchange on a basis of personal 
relationship, integrity, quality, need, and environmental soundness rather than simply for 
money. (But it does include exchange for money.) It includes an innovative moneyless 
exchange based around favours. See description below. 

• Organisational support such as group editable pages (wiki), a list of members with fields 
for roles and responsiblities, a template for lists of agreements, task trackers. 

Individual user areas 

Individual users should be identified with a user name that normally would be there real 
name and an avatar. Clicking on either should link to their profile page. 

An individual's profile page include a description of them entered through a set of fields 
including name, location, and a WYSYWIG editable field for general information. 

They should be able to create the same types of content as a group, and the profile page 
should include lists of the content created by them, arranged by content type. 

It should also include their exchange 'partners', as described in the exchange section 
below. 
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5 Discussion system 

Good communication is what makes a community work together effectively. What is 
important is: 

• that people are able to contact each other easily. 

• that they know they have been understood and are able to come to agreement. 

• that when their views diverge, they are able to resolve conflicts creatively, in ways that 
satisfy all parties. 

Thus we are proposing communication tools that go well beyond standard email and 
online forums for this purpose. 

In addition to the main online discussion tool (described below and in more detail in 
Appendix 1) we propose to provide 

• group chat to allow online simultaneous meetings by groups using text 

• telephone conferencing, to allow voice conferences by groups that are easier to attend 
than face-to-face meetings 

• a community call centre, in which a published telephone number can be connected to 
people who take turns at being on call to provide immediate help or telephone 
connection to someone else who can help, in a range of different areas, (for example, 
technical help with computers, rides wanted, emergency help of some kind, etc.). 

The need for moderators 

Skillful facilitation is important in any group discussion that has a more serious purpose 
than casual chat, whether face-to-face or online. A good facilitator will help keep the 
discussion on track, ask leading questions to move the discussion on, make sure everyone 
is heard and acknowledged, and summarise important points and decisions. 

At the Open University, with large numbers of students online working collaboratively, each 
small group had a moderator, who was trained in moderation skills. The moderators had a 
discussion which was well used and very valuable. If we expect our community 
discussions to work well, we will need to do something equivalent. 

There will also need to be a well constructed set of help files, and pop-up hints created for 
users and especially for moderators. 

Summary of features of the discussion system 

This proposal builds on best practice in existing online forums and builds on long 
experience at the Open University: 

• Flexible email notification of new messages but fullest display online. 

• Discussions available wherever needed: in groups at all levels, in individual folders for 
small private discussions 

• Simple linear chronological display, but with ways to display comments on given 
messages. 

• Special message types: 'summary' messages, message type for 'sensitive' issues, and 
polls for checking agreement 

• Clear indication of new messages in a discussion (since last logged in) 

• Facilities to support moderators to keep discussions effective. 

See Appendix 1 for a more detailed specification. 
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6 Exchange system 

The essence of a Connected Community is people doing things for each other on an 
organised basis: seeing each other as partners rather than in competition or against each 
other. The exchange supports the practical, daily embodiment of this: helping people to 
obtain their food, transport, childcare, services, goods, etc. and enabling them to ask for 
help or support for themselves or for a group. 

The exchange consists of 3 parts: 

1 . Current listings of offers and wants for money or as favours. These will be one-offs, 
short-term, or transitory. It could include such things as goods that are no longer 
needed that are offered for free (a Freecycle function), special offers from a business, 
help or services needed by an individual or group, etc. 

2. the Directory, of shops, tradespeople, or other businesses made up of entries that 
record ongoing offers of goods or services. The entries may ask for monetary payment 
or may offer favours, perhaps only to specified people or groups. The entries may have 
feedback attached from previous recipients. 

3. a Partner Network, which enables people to see their connection to others in terms of 
exchanges given and received. This is built out of a Feedback record system, 
containing acknowledgments for favours and other exchanges received and given. 
With it, if they are asked for a favour by someone they do not know, they can see if 
there is an indirect link: that person has done something for a group or a person that 
has done something for them, perhaps through more than one step. 

See Appendix 2 for a more detailed specification of the exchange system. 
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7 Development process 

The specification in this document is large and rich. Building it in full and then trying to 
recruit communities to use it is likely to be an expensive, slow and perhaps futile exercise. 
It is better seen as a vision, a pointer to possibilities. Implementing it should be a process 
working together with target communities, starting with some limited functionality, seeing 
what works for them, and building from there. 

Ideally, this platform should be entirely an open source project, freely available to all with 
further development by whomever wants to do so. The most suitable starting point would 
thus be some well supported open source CMS like Plone or Drupal. 

In practice, the starting points and development process are likely to be more pragmatic. 
We will need to investigate what existing platforms can easily put together a starting point 
that incorporates much of this specification and allows further development. 

It may even be necessary to build prototypes out of commercial software such as Ning, 
with mashups to add extra features, as a quick start that tests the functionality. 

At this stage, I welcome comments and suggestions, especially for suitable starting points 
and teams that want to implement this. 
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Appendix 1 - Detailed specification for discussion 
system 

Overall structure: 

The discussion system should consist of 'conversations' that in turn are made up of 
'threads' that in turn are made up of 'messages'. 

Conversations: 

1 . A conversation can be created by any registered user in the context of any group of 
which they are a member or the user's personal folder. 

2. A conversation has a list of members. By default, the members of a conversation 
created in a group folder are all the members of that group. 

3. Members of a conversation have rights to create new threads, write messages to 
existing threads, and edit and delete messages they have previously written. 

4. The creator of a conversation is its owner. The owner has additional permissions to 
delete the conversation, to remove and edit threads and messages in threads, and to 
remove members. 

5. The owner of a conversation also can create and remove additional owners, and can 
create and remove 'moderators', who are members with additional permissions to 
remove and edit threads and messages in threads, and to remove members. (So there 
are three classes of member: owner, moderator, member.) 

6. A conversation is normally visible to anyone who can access it, whether or not logged 
in, but non-logged in users cannot write to it. 

7. When a conversation is created, the owner can adjust the usage and membership: it 
can be made private, so it can only be viewed by users who are members of the group 
containing it. If it is created in a group folder, it can be made open to other groups. If it 
is created in the owners personal folder, the owner can specify groups or individuals to 
whom it is open. 

8. Upon creation, a conversation should be given a short description. 

9. Display of a conversation: A conversation should be displayed on a portal-like front 
page of the place where it is created: a group folder, or a user's personal profile page. 
Each conversation displayed should first show the owners' avatar, its description and 
creation date. It should then show a sequence of small avatars of the members who 
have created messages in it, in order of most recent contribution, up to a maximum 
limit of members. It should then show lines giving summaries of each thread (see 
threads). 

10. Before the list of threads there should be an 'add new thread' button, which should 
appear greyed out to users without suitable permissions (i.e. not logged in, or not in 
group). 

1 1 . Upon creation a thread should be automatically created called 'moderation' which is 
visible and writable only to members who are moderators or owners. 

Threads: 

1 . A thread has a creator, a creation date, a subject and an initial message. (Individual 
messages that make it up do not have their own subject.) 

2. The creator of a thread has no special privileges in it. Only moderators and owners 
have additional privileges. 

3. A thread can be displayed as a summary (in the display of a conversation) or in full. 
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4. The summary display of a thread should include its subject and creation date, the 
number of messages, the avatar and date of the most recent message. 

5. For logged in members of a conversation, the summary display of each thread should 
be preceded by the number of messages that were created since their last login, to 
give an indication of how much new content has been added. 

6. The full display of a thread should consist of a linear, chronological sequence of the 
messages in it, oldest first, so it can be read in sequence. For logged in members, 
there should be a suitable symbol in front of each message added since they last 
logged in so they can easily scroll to what is new. 

7. At the beginning of the full display there should be buttons for 'new message' and 
'delete thread', which should be greyed out for users without suitable permissions. (For 
other controls, see below.) 

Messages: 

1 . Messages have creators, creation dates, and a body. 

2. When a message is created or edited a standard WYSIWYG editor such as Kupu, 
TinyMCE or FCKeditor should appear, but with a fairly limited set of styles. 

3. In addition, the editor should have buttons for three types of special message: 
'summary', 'poll', 'sensitive', intended to promote convergent conversations, where 
people are encouraged to come to agreement. 

4. A 'summary' message, is an ordinary message, indicated in some fashion, such as a 
different coloured border. It's use (purely social, no attempt to enforce it through 
software controls) is to summarise recent messages. Thus users wishing to get an 
overall sense of the thread can scroll through, looking for the summaries. At the head 
of a thread should be a 'show summaries' button, changing to 'show all' when pressed. 
When pressed, all messages that aren't summaries should be greyed out to make 
summaries stand out clearly. 

5. A 'sensitive' message is meant to used in situations where there is an actual or 
possible conflict between users. It is an ordinary editable message with three fields 
defined headed, respectively: 'Your view as I understand it', 'Where I agree', 'Where I 
disagree'. 

6. New messages in a thread can be created simply as an addition to the thread, or as a 
comment on an earlier message in the thread. Each message should have a 'comment 
on this' button (greyed out if the user doesn't have suitable permissions.) Messages 
that are comments are still displayed in linear, chronological sequence. 

7. Each message should have a 'display comments' button, greyed if there are no 
comments. Pressing it should grey out all subsequent messages that are not 
comments on that message, making them stand out. (It should change to 'display all' 
when activated.) 

8. Quoting text: If a user selects text either in the initial message of a thread, or any other 
message, the new message created will include that selected text, indicated stylistically 
as a quotation. 

9. Each message should have a 'report to moderators' button (greyed out to those without 
suitable permissions). When pressed, an editor should appear with a field headed 
'reason for reporting this message'. When sent, the message will appear in the 
moderators thread. 

Email notification 

Email is still the dominant application for most people, many of whom don't check it that 
often, and would not be likely to check a website to find out if there are new messages in a 
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conversation. Thus, we need to offer an option of email notification of new messages in an 
online discussion. 

1 . There should be a control at the level of a conversation and each thread saying 'email 
on off' with the 'on' and 'off' buttons highlighted as appropriate. 

2. Switching email on at the level of a conversation switches it on for all threads in that 
conversation and for all new threads created. Switching email off on a thread overrides 
this. If email is off for a conversation, it can be switched on or off for each thread 
separately. 

3. If email is on for a thread, then when a new message is created, a mail message is 
sent to that user that includes the full body of the message. The sender of the message 
should be the creator of the message, the subject should be the subject of the thread. 
The body of the message should be preceded by a statement such as "You have 
requested email notification of this message. You can see it in context, reply to it, or 
switch off email notification at: [URL]." The body of the message should then follow. 
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Appendix 2 - Detailed specification of the exchange 
system 

Preamble: 

The essence of a Connected Community is people doing things for each other on an 
organised basis: seeing each other as partners rather than in competition or against each 
other. The exchange supports the practical, daily embodiment of this: helping people to 
obtain their food, transport, childcare, services, goods, etc. and enabling them to ask for 
help or support for themselves or for a group. 

It is designed to promote exchange on a basis of personal relationship, integrity, quality, 
need, and environmental soundness rather than simply for money. (But it does include 
exchange for money.) 

The major innovation of the exchange is that it sets up a system of money-less exchange 
based around 'favours', which, unlike a currency, are not measured or denominated. This 
is a simpler alternative to complementary/community/local currencies that are 
denominated in hours or arbitrary units. Favours are acknowledged with feedback and 
recorded so that people's contributions to each other, to a group or organisation or to the 
community can be seen and appreciated. [Appendix to be written fully explaining and 
justifying this.] 

Where conventional social networking sites have 'friends' with no real function other than 
some sort of play, with the exchange we have 'partners', people who do 'favours' for each 
other. Through the exchange in a connected community you can build up a network of 
people for whom you have done favours (directly or indirectly) and from whom you can 
reasonably expect favours in return. 

An important function of the favours-based exchange is to encourage voluntary 
contributions to a group or the community, as these will be recognised with feedback. 

To improve conventional (money-based) exchange the exchange provides a Directory of 
local services and businesses that includes opportunities for customers to post feedback, 
recommendations and reviews. Customers can post Feedback indicating satisfactory 
completion of a transaction. Also, Directory entries should include some way of 
commenting/indicating environmental soundness and community participation. Note that 
this is a directory only, not an online trading system. Contacting, agreeing, carrying out the 
transaction and paying for it are outside of the system. 

A secondary purpose of the exchange is to create a social mechanism for promoting 
integrity and quality in transactions and to handle disagreements and conflicts. For this to 
work effectively, the exchange needs to be supported by a team of mediators. The 
feedback of transactions, whether favours or paid, must either be positive or if not, should 
be passed through the mediation team. 



Overall structure 

The exchange consists of 3 parts: 
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4. Current listings of offers and wants for money or as favours. These will be one-offs, 
short-term, or transitory. It could include such things as goods that are no longer 
needed that are offered for free (a Freecycle function), special offers from a business, 
help or services needed by an individual or group, etc. 

5. the Directory, of shops, tradespeople, or other businesses made up of entries that 
record ongoing offers of goods or services. The entries may ask for monetary payment 
or may offer favours, perhaps only to specified people or groups. The entries may have 
feedback attached from previous recipients. 

6. a Partner Network, which enables people to see their connection to others in terms of 
exchanges given and received. This is built out of a Feedback record system, 
containing acknowledgments for favours and other exchanges received and given. 
With it, if they are asked for a favour by someone they do not know, they can see if 
there is an indirect link: that person has done something for a group or a person that 
has done something for them, perhaps through more than one step. 

Current Listings 

1 . A summary list of current listings should appear in several places: 

1 . On the front page of the portal there should be a limited number of entries, including 
the most recent urgent wants, and the most recent other additions. 

2. In a dedicated Listings folder, similar to the front page but with more entries 
displayed by default. 

3. In a Group's front page, but restricted to entries indicated as visible only to that 
group. 

4. On a user's home page, but restricted to listings the user has created. 

2. The summary list should be displayed as a table that enables a choice of displays: 
ordered by date available, by name of person entering it, by urgency (i.e. listings 
marked urgent first), by key word clickable from a tag cloud, through a search field. 

3. The summary of a listing should include: 

1 . date available 

2. name and avatar of creator linked to their profile, 

3. offered or wanted, 

4. favour or paid and if paid, a price, 

5. option of 'urgent', 

6. a descriptive title with a small character limit, 

7. a thumbnail picture. 

4. The summary listing should be accompanied by a tag cloud of key words of the listings 
included. 

5. The summary listing should include buttons 

1 . to go to a separate page with the complete, or longer summary table of listings 

2. to allow a user with suitable permissions to add a new listing. Activating this should 
open a template allowing creation of the full listing. 

6. Full display of a listing: Two possibilities should be considered: 1) That a full listing be 
displayed on a page of its own or 2) That a listing in full should be displayed in place, 
with the following listings sliding down to make room for it when it is selected. 

7. The full listing consists of the following fields to be filled out by the creator: 

1 . The name and avatar of the creator should be inserted by default, 

2. Categories: Key words displayed as a tag cloud. 
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3. Time limits of availability: A choice between various times, probably with a 
maximum of one year, and 'until date....' with available now as the default. 

4. Quantity limits: Unlimited, or number. 

5. Contact information: (phone, email, address) 

6. Availability: (ex: direct from address, through shops, markets, mail order, etc.) 

7. Display to: all, specified group(s). 

8. General description. This should be a full WYSIWIG editable field, with formatting, 
pictures, links. 

9. Field for 'Comment on environmental soundness' (or equivalent). 

8. Listings created in a group folder are a special case. In addition to being offered by an 
individual they should offer the option of coming from the group as a whole although 
they are created by a member of the group. This enables people to give to or receive 
from a group, or the overall community, and be acknowledged for that. 



The Directory and its Entries 

The most important aspect of the Directory is ease of finding relevant entries when people 
have specific interests, but the default view should also present some serendipitous 
entries such as recent additions or changes. 

1 . The Directory displays a tabular summary view of entries, which contain links to each 
full entry. 

2. The summary view of an entry should contain some keywords or categories, the name 
and avatar of its creator, a location, a title, a short description (limited number of 
characters). 

3. The table of summary views of entries should be displayed with a heading row that 
gives display options in each column. So clicking on the keyword column orders the 
entries in alphabetical order of keyword (or reverse alphabetical order), and similarly 
with name of creator, location, title. 

4. Searching: a 'live search' facility should be included, with entries appearing as letters 
are typed in. Alternatively, the search results should appear in the same format as the 
full summary table. A third alternative should be a tag cloud of keywords. 

5. The directory entries should be displayed in full on their own page, with facilities for 
feedback (see below). 

6. The directory entry should start with the summary view, and be followed by a body 
consisting of fields for: 

1 . Contact information: phone, email, address, map 

2. General description. This should be a full WYSIWIG editable field, with formatting, 
pictures, links 

3. Fields for the creator to put in comments on environmental soundness and 
community connection, with suitable instructions. 

7. Once published, a directory entry should have a button to enable people to create 
comments on their experience with that business. [To be elaborated] 

8. When creating a directory entry the creator should be able to specify its visibility: i.e. to 
all, to specified groups. 



The Partner Network 

[Note: I see this as both the least formed and the most important part of this specification. I 
need people's reactions to the concepts and the terminology] 
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The Partner Network is meant to create a direct sense that people are connected and 
support each other in practical ways. It is also meant to encourage them to be clear that 
transactions, whether favours or for money, have been completed to mutual satisfaction. 

1 . For each participant in the exchange, there should be a personal partner network that 
consists of a set of other participants and for each of those, a set of transaction 
records. Each transaction record gives a summary of a past transaction between the 
two participants. 

2. A person's current set of partners should be displayed on their public profile page. For 
each, clicking on the avatar or name should link to the partner's profile page. 

1 . For each partner there should be an avatar and a name, a 'satisfaction rating' 
which is the average of the satisfaction ratings for all the transactions with that 
person, and a button that displays the set of transaction records for that partner. 

2. They should be able to be listed either in order of most recent transaction or by 
name, up to a specified number of entries. There need to be mechanisms to find 
those not shown in the default listing, including a live search, and 'view more' 
control. 

3. A transaction record describes the results of a transaction which might either be a 
favour (done without monetary payment) or something done for monetary payment. It 
may be the outcome of a Current Listing offer or want, a listing in the Directory, or 
completely independent of these. 

1 . Controls to 'create a transaction record [better terminology?]' should appear both in 
the Current Listings and the Directory. 

2. A control to create a transaction record should also appear with the partner listing, 
to enable records of independent transactions to be created. 

4. A transaction record should include the following fields: 

1 . The person giving and the person receiving 

2. Whether this was a favour or for money, and if the latter, how much. 

3. The date 

4. Brief description of the transaction (limited number of characters). 

5. Fields for both people to record their satisfaction, on a simple scale (1 -5, 1 -1 0?) or a 
star rating. 

5. When creating a new transaction record as much information should appear by default 
as is possible from the context: giver, receiver, description, favour/money. If there are 
no previous transactions between the creator and the other person, then that other 
person is added to the set of partners. 

6. Transaction records can be created by the giver or receiver but displayed in the partner 
records of both. When completed by one, a message should be sent to the other 
inviting them to complete their satisfaction rating. 
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